Making Remote Procedure Calls

At times a preemptive task may need to call a system software function, and doing so may cause problems. For example, many calls to Mac OS system software manipulate global variables, so data could easily be corrupted if more than one task attempts to make similar calls. To work around this problem, Multiprocessing Services allows you to make remote procedure calls if you need to call system software from a preemptive task. A remote procedure call also allows your task to call 68K code.

IMPORTANT

A subset of system software calls, as described in Preemptive Task-Safe Mac OS System Software Functions , are preemptive task-safe in Mac OS 9. However, with the exception of the functions in Multiprocessing Services, you should assume that all other system calls are unsafe. Even if some system software function appears to work today when called from a preemptive task, unless explicitly stated otherwise there is no guarantee that subsequent versions of the same routine will continue to work in future versions of system software. In the Mac OS 8 and Mac OS 9 implementations of Multiprocessing Services, the only exceptions to this rule are the atomic memory operations (such as AddAtomic ) exported in the InterfaceLib shared library. Even these functions may switch to 68K mode if the operands to them are not properly aligned.

To make a remote procedure call, you must designate an application-defined function that will make the actual calls to system software. You then pass a pointer to this function as well as any required parameters in the MPRemoteCall function.

Note

Since your application-defined function must be written in PowerPC code, you do not need to build a universal procedure pointer to pass to the MPRemoteCall function.

When you call the function MPRemoteCall from a task, that task is blocked, and the application-defined function you designated then executes as a cooperatively scheduled task, which can make system software calls with no danger.

Note that when you call MPRemoteCall , you can designate which context (or process) you want your application-defined function to execute in. If you specify that the function should execute in the same context that owns the task, the function has access to data available to the main application (just as if the application had called the function). However, the function cannot execute until the owning context becomes active (and then not until the application calls WaitNextEvent ). Alternatively, you can designate that the function execute in any available context. Doing so minimizes possible lag time, but the function cannot access any resources specific to the task's context.

IMPORTANT

In the future, individual application processes may not always share the same address space, so in general you should never attempt to access code or data in another process.

After your application-defined function returns, the task is unblocked and execution proceeds normally.

© 1999 Apple Computer, Inc. – (Last Updated 17 Nov 99)